To address issue #136

Currently the restG4 simulations do not accept nested volumes because TRestGeant4GeometryInfo::PopulateFromGeant4World only goes through the direct children of the world. Also, the relation between the fGdmlNewPhysicalNames (the names of the PV in the gdml) and the names of the PV inside Geant4 is done assuming that the gdml ordering of the PV is the same than the ordering of the Geant4 world daughters. This is correct when you don't have nested volumes (nested assemblies do because their children are imprinted as a regular direct children of the mother volume where the assembly is placed). When you have nested volumes, this ordering gets trickier because it depends on how you travel into the daughter volumes.

So this related PRs (#144 and rest-for-physics/restG4#141) proposes a change in the way the mapping of Geant4 PV <-> gdml pv names is done. Instead of relying in the ordering of the traversing of the daughter volumes, we will associate them by their name, which should match. Unfortunately, there are two problems:

1. Daughter PV are named the same when the mother LV is placed several times. Also, the G4VPhysicalVolume objects don't have information upstream further than their mother LV.
2. When a PV is placed from an assembly, its daughter physical volumes are imprinted into the mother volume where you are placing the assembly. This daughter PV are named following the format: av_WWW_impr_XXX_YYY_ZZZ, where WWW is the assembly volume number, XXX the counter for the number of imprints of that assembly volume, YYY is the LV of the daughter and ZZZ is a suffix 'pv_z' where z is the number of that daughter inside the assembly volume. Unfortunately, this is badly implemented inside Geant4 and, when having nested assemblies, the daughter physical volumes defined after a nested assembly gets the imprint number XXX+1 instead of the XXX of its mother assembly imprint and keeps the WWW of the mother assembly (instead of its own).

The idea is then to traverse recursively the daughter volumes of the geometry keeping track of the path so we get the full path of the PVs with the Geant4 naming. This way we workaround the problem 1. For example we would get:
av_7_impr_1_outerGasLV_pv_2/av_6_impr_1_gasLV_pv_1/av_1_impr_1_mMBoardCopperLV_pv_11/mMBoardKapton/mMCopperFoilLayer2

On the other hand, the gdml path of physical volumes positioned is in this example:
shielding/outerGas/vessel/gas/micromegasRight/mMBoardCopper/mMBoardKapton/mMCopperFoilLayer2

To convert the Geant4 path to the gdml we need to replace the av_WWW_impr_XXX_YYY_ZZZ for its assemblyVolumeName/daughterPVname. The method TRestGeant4GeometryInfo::GetAlternativePathFromGeant4Path is implemented for this. The information needed for this step can be gathered in the TRestGeant4GeometryInfo::PopulateFromGdml method and saved inside members of TRestGeant4GeometryInfo, so it can be used in the method TRestGeant4GeometryInfo::PopulateFromGeant4World to convert the Geant4 paths to the gdml paths. The changes of this PR do exactly this.